Counter performance increase by incrementing atomics immediately when no attributes are provided #1563
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #
Design discussion issue (if applicable) #
Changes
Previously, atomics were managed by the
ValueMap
itself in themeasure()
function. This meant that everycounter.add(1, &[])
call would have to go through several boxed function calls, plus the non-zero cost of creating an empty attribute set. Moving the incrementing of atomics in the no attribute into the SDK's counter implementation directly bypasses all of these costs for significantly faster counter addition.Since logic for managing these atomics was moved into multiple call sites, the original
AtomicTracker
trait was renamed toAtomicValue
to better represent what the trait is calling. A newAtomicTracker
struct was created to manage both theAtomicValue
and anAtomicBool
so that aggregations know if they have a no-attribute value that should be exported or not.Benchmarks
main:
This PR:
Merge requirement checklist
CHANGELOG.md
files updated for non-trivial, user-facing changes